GH-49942: [Python] Protect PyBuffer and NumPyBuffer destructors against interpreter finalization - #49943
Conversation
… against interpreter finalization
|
@github-actions crossbow submit -g python |
|
Revision: bbe7634 Submitted crossbow builds: ursacomputing/crossbow @ actions-62ce37605c |
|
@github-actions crossbow submit wheelmac* wheelwin* |
|
Revision: bbe7634 Submitted crossbow builds: ursacomputing/crossbow @ actions-62ea8dd650 |
|
After merging your PR, Conbench analyzed the 0 benchmarking runs that have been run so far on merge-commit d4e0e26. None of the specified runs were found on the Conbench server. The full Conbench report has more details. |
|
After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit d4e0e26. There was 1 benchmark result with an error:
There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them. |
… against interpreter finalization (apache#49943) ### Rationale for this change In apache#38637 we protected the `OwnedRef` and `OwnedRefNoGIL` destructors against being called when the Python interpreter is being finalized, but we didn't address other classes with custom destructors, such as `PyBuffer` and `NumPyBuffer`. ### What changes are included in this PR? Avoid executing Python C API code if the interpreter is finalized while a C++ destructor runs. ### Are these changes tested? Only manually, using the initial reproducer in apache#45214. ### Are there any user-facing changes? No. * GitHub Issue: apache#49942 Authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>
Rationale for this change
In #38637 we protected the
OwnedRefandOwnedRefNoGILdestructors against being called when the Python interpreter is being finalized, but we didn't address other classes with custom destructors, such asPyBufferandNumPyBuffer.What changes are included in this PR?
Avoid executing Python C API code if the interpreter is finalized while a C++ destructor runs.
Are these changes tested?
Only manually, using the initial reproducer in #45214.
Are there any user-facing changes?
No.